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ACCESS.bus, an Open Desktop Bus 

With the recent introduction of the ACCESS.bus product, Digital has affirmed its 
commitment to open systems and thus to facilitating belter solutions Jbr inter* 
active computing. This open desktop bus provides a simply uniform way to link 
a desktop computer to as many as 14 tout-speed I/O devices such as a keyboard, 
mouse, tablet, or three-dimensional tracker. ACCESS.bus features a JOO-k'Slobitper- 
second maximum data rate, hardware arbitration, dynamic reconfigus/tuion, a 
mature capabilities grammar to support generic device drivers, and off-the-shelf 
low-cost PC microcontroller technology 



As the cose of persona) interactive computing 
decreases; the range of applications and Che need 
for specialized I/O devices Is growing dramatically; 
Traditional personal computers were designed to 
Accept only a small number of standard devices; 
adding devices beyond those originally envisioned 
usually requires specialUed hardware or software. 
Custom interfacing is expensive for vendors ind 
users and thus limits the availability of new devices. 

ACCESS.bus provides a simple, uniform way to 
Jink a desktop computer to a number of low-speed 
t/O devices such as a keyboard, a mouse, a tablet, or 
a three-dimensional (3-D) tracker. Designed from 
the beginning as an open desktop bus, ACCESS.bus 
facilitates cooperative solutions using equipment 
from different vendors. This paper describes the 
ACCESS.bus design and gives some insight into how 
the idea was adopted at Digital. 

Design Goal, Process, and Advantages 
The design goal for the desktop bus follows from 
our experience within che Video, Image and print 
Systems (V7FS) Input Device Group with trying to 
support new devices on Digital terminals and 
workstations. While various new devices have been 
successfully prototyped over the years, Che need 
for nonstandard hardwure and custom software 
drivers was always nn expensive, time-consuming 
obstacle. Even after successful prototyping, these 
devices could not be readily adapted to our stan- 
dard systems, limiting their use to custom applica- 
tions. Iu designing the desktop bus, our goal was to 
make it as easy as possible to interface previously 
unavailable I/O devices to our systems in a way 
that was both practical and marketable. This sec- 
tion explains the benefits of using a desktop bus 



describes the process we wr_nt through to convert 
to a new bus architecture, and summarizes the key 
advantages of the chosen, design. 

The basic desktop bus concept is illustrated in 
Figure 1. The bits allows multiple, low-speed I/O 
devices to be interconnected and thus interfaced 
through a single host port. Desktop bus devices 
such as =i keyboard or a tabkt, which arc not hand- 
held, provide two connect tirs and allow another 
device to be daisy chained, a hand-held device 
such as a mouse cun be pluced at the end of the 
daisychaijn, or a connector expansion box can be 
attached to accommodate additional devices that 
do not provide two connectors. 
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Figure 1 Basic Desktop Bus 
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The desktop bus has the following benefits; 
* Enables grater flexibility and variety of use 
■ Reduces the cost of connecting multiple devices 
m Expedites bringing new technology to market 
- Helps leverage third-parry devices 

The first benefit, greater flexibility, can be simply 
achieved by all owing .additional devices and more 
modular solutions. We further extended this bene- 
fit.by designing a way for devices to be added at run 
time without disrupting system operation. Con- 
figuration should be automatic; connecting stan- 
dard device* should not require powering down or 
rebooting the system before a new device can be 
used. The desktop bus supports multiple, like 
devices without switches or jumpers. 

The second benefit, reduced cost, was crucial to 
having the bus accepted a* a solution across a wide 
range of products from low-end video terminal* 
to high-end workstations. We recognized that con- 
temporary electrical techniques could eliminate 
the need for level translation circuits, -12 volt (V) 
power supplies, and perhaps some of the protec- 
tive components used with RS-232 interfacing. 
Although many devices would now require two 
connectors, system cost would decrease because 
we would need to supply only as many connectors 
as chc number of devices to be attached, or possibly 
one more. 

The third benefit, expediting the time to market 
for new technology, allows us to better satisfy 
changing requirements. Key to this benefit is hav- 
ing the means to connect new devices without 
changing the system hardware or software. Based 
on our experience with input devices, we devel- 
oped the concept of device capability reporting 
and generic device protocols. Standard devices 
like keyboards and locators, eg., mice, tablets, and 
trackballs, all work in similar ways. For this class 
of device, we define a simple device protocol and 
a way to parameterize and report device unique 
characteristics. A single generic driver can adapt 
itself to work with a does of similar devices so 
that no custom software is required for basic opera- 
tion of standard devices. 

Leveraging third-party devices, the fburdi 
benefit, is aimed at satisfying diverse customer 
requirements. Because the use of computers con- 
tinues to proliferate, the range of applications far 
exceeds thai which any one vendor can mastec 



By making the bus truly open, we encourage third 
parties to add value to our systems. 

The benefits of a desktop bus tire significant. But 
converting to a new architecture, especially one 
that is not backward compatibly is expensive in 
terms of the time and effort required. How docs a 
large corporation build agreement to make such 
an investment decision? The desktop bus project 
started as a grass roots engineering effort and grad- 
ually built momentum- The process was one of 
dialogue to attract partners. Initially, three groups 
with slightly different objectives; worked together 
to develop the bus. The visibility of separate groups 
jointly supporting the bus concept was essential to 
transform the idea into action. People art more 
willing to accept an idea that ochers around them 
have already adopted. 

The three groups that initiated the desktop 
bus project were our vips Jnpul Device Group in 
MFestford, MA, mentioned previously; the Work- 
station Systems Engineering (W:<E) Group, located 
in Palo Alto, Ca; aod the Video Advanced Develop- 
ment (a/0) Group in Albuquerque, NM, Our Input 
Device Group was looking for ways to simplify the 
process of prototyping specialized input devices 
and of getting related software support for our 
video terminals and workstations. WSE was devel- 
oping a low-cost, personal workstation and needed 
a flexible way to support muiiJplc input devices 
without greatly increasing the cost of the base 
workstation- The Albuquerque a, TD Croup had been 
experimenting with next generation I/O devices, 
i.e., force-feedback joysticK, 3-13 tracker, and real- 
time audio and video, and was interested in having 
these technologies adopted by other Digital groups. 
This A/D Group had \ised 1 2 C technology success- 
fully in one of its previous video projects. 

In January of 1990, engineers from each group 
realized tfiey were working on similar problems 
and began to collaborate. The *tfSE Group was to 
build the desktop bus host interface and software 
drivers into their workstation; the VIPS Group was 
to help define the device proiocols and supply 
desktop bus keyboards and mice; *nd the Albu- 
querque A/D Group was to support bus devel- 
opment and prototype additional devices, wjrhln 
four months, vips bad defined ilie basic protocols 
and could demonstrate a working l*C keyboard 
and mouse. These early prototypes helped per- 
suade WSE to support the project and, in turn, 
helped reinforce the importance of the project to 
the vtps Group. 
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We began presenting the desktop bus idea to 
interested groups within Digital and received many 
useful suggestions including 

■ Use the same keycodes as on the LK201 keyboard 
to eliminate the need to rewrice keyboard 
lookup tables, 

■ Store che country keyboard variation inside 
the keyboard so users will not need to enter it 
manually. 

» Keep the devices simple, without modes. 

In addition, third-party input device vendors 
made tiic following suggestions, 

• Use a modular connector that is easy co phig and 
Unplug corrccrly 

■ Provide enough power for several additional 
devices. 

• Allow vendors to supply their own device 
drivers: tuning their own device drivers is part 
of the value added by the vendor. 

The bus idea was elegant and generally well 
received, Most of the reservations centered around 
the likely impact on existing system components, 
the current problems, and whether conversion to 
the bus was feasible. Because we recognized that 
other groups were facing tight development scticd* 
ules, wc did not pressure these groups to support 
our desktop bus work. Wc presented the desktop 
bus as a possible solution to interface problems, 
made our design information available, and worked 
co incorporate suggestions. But as the development 
work progressed, more partners supported our 
effort. 

Once we decided to use a desktop bus, wc 
looked at available designs, including the Apple 
DcsJcTop Bus, the Musical Instrument Digital 
Interface (MIDI), and serial buses offered by other 
semiconductor vendors, and evaluated these alter- 
natives widi respect to our design goal. Key advan- 
wges of the design chosen, i.e., the ACCESS.bus, are • 

■ Off-the-shelf interintcgratcd circuit (PC) micro- 
controller technology with maximum data rate 
of loo kilobits per second (kb/s). This technol- 
ogy is iow-cost, yer fast enough for sophisticated 
input devices like a 3-D tracker. 

■ Built-in hardware arbitration, which simplifies 
the software and allows reliable communication 
wjthour inventing a ne**- protocol. 



■ Dynamic reconfiguration. The hardware and 
software allow bus devices to be "hot-plugged" 
and used immediately, without restarting the 
system. The devices arc recognized automati- 
cally and assigned unique addresses. This advan- 
tage results in aplug-and-play user interface. 

■ A mature capabilities gram .mar co support generic 
device drivers. An extensible free- form grammar 
allows devices to describs their characteristics 
to n generic driver. Most common devices can 
work wjdi standard drivers. 

Bus or network interconnection has become 
widely accepted as a means; of providing flexible 
open solutions. To appreciate ACCESS.bus, U is help- 
ful to position its perforrnsince capabilities with 
respect to those of other network interconnect 
technologies, as shown in Table l. 

Table 1 Network Interconnects 



Bus TVpo 



Order of Magnitude 
Performance 
(kilobits per second) 



Apple DeskTop Bus, 
ACCESS.bus 

LoealTalk 

Ethernet 

FODI 



10-100 

100-1,000 

1.000-10,000 

10,000-100,000 



At first glance, the 100-kb/s speed of the 
ACCESS.bus may seem adequate for large desktop 
devices like printers and modems. But these 
devices can transmit long data screams indepen- 
dent of any user activity and, not restricted, could 
compromise the inceraeclve performance of the 
bus. Thus, ACCESS.bus is intended for low- speed 
activities that people perforin with cheir hands 
and is fast enough to handle multiple interactive 
devices like a keyboard, mouse, or 3-D tracker. 

Hardware Description 
Before discussing the ACCESS.bus design, we pre- 
sent a description of the Philips I*C technology 
upon which the design is bsised. Details of the 
specific ACCnss.bus implement at ion follow 

Intiertntegrated Circuit Fundamentals 
ACCESS.bus extends the Philip;; PC bos to operate 
off-board and, thus, connect desktop devices. The 
I*C is a two-wirc serial clock uid serial data 
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open-colkctor bus. An open-collector design means 
that the clock and data lines arc normally in a high* 
impedance floating scare and are pulled up to a log- 
ical high stare. 

A device that -wants to send a message waits for 
any message frame in progress co complete, then 
asserts a START signal to become bus master and 
begins to generate data and clock signals. The bus 
clock is synchronized among all devices by its 
wired AND connection. Each device, wheiher 
transmit ting or receiving , stretches the low period 
of the clock until ready for the next bit to be trans- 
ferred. When the last device is ready, the bus dock 
is allowed to go high, generating a rising edge on 
the serial clock. At this time, all active devices 
sense the state of the bus data line. For a receiving 
deviec, the state represents the received data bit. 
For a transmitting device, the state determines 
whether the device has successfully asserted its 
data on the bus. a transmitter that is sending a logi- 
cal high state and detects that the data line U being 
held low by another sender, recognizes that it has 
lost arbitration and must try again later. "wlien a 
"collision" or arbitration occurs, no data is lost, one 
message is transmitted and received, and the 
remaining messages must be sent again. 

PC data messages are transmitted as 8-bit bytes, 
with each byte being acknowledged by a ninth 
ACKNOWLEDGE bit from the receiver. PC technol- 
ogy also defines unique START and STOP signals to 
delimit message frames, The first byte of any mes- 
sage frame is always the destination address. 

ACCESS, bus Physical Implementation 
Details of thephysical Implementation of ACCESS, bus 
are as follows: 

« Basic electrical configuration. ACCESS, bus uses 
four-pin, shielded, modular-type connectors thi\t 
feature positive orientation and locking tabs. 
Data and po^ex for the bus arc transmitted over 
Jaw-capacitance, four-wire, shielded cablc.'nic 
four conductors are used for ground, serial data, 
serial dock, and +12 V 

■ Available power. The maximum available power 
for ail devices is 12 v at 500 mJULampercs Otia). 
ACCESS.bus devices may supply their own power 
from a separate source, if needed. A power-up 
reset circuit must still be provided to reset the 
device when bus power is applied. 

» Cable length. The maximum cable length for 
the entire bus is 9 meters. The limiting factor is a 



maximum capacitance not i:o exceed 700 pico- 
farads (pfO. 

■ Number of devices. The nuximum number of 
ACCESS.bus devices allowed on the bus is 14. 
Limiting factors arc the device addressing range 
and the power distribution <> total of 500 mA for 
all devices). 

* Hardware interfaces. ACCESIi.bus hardware inter- 
faces arc implemented using standard I 2 C micro- 
controllers developed by ths: Signetics Company 
or under license from Philips Corporation. (Sig- 
netics Company is a division of North American 
Philips Corporation.) 

ACCESS.bjis Protocol 

Every device on the bus is a microcontroller with 
an PC interface and behave;? as cither a master 
transmitter or a slave receiver, exclusively, as 
defined by the I a C Bus Specification. 

Message Format 

A message transmits information between a device 
and the computer or between the computer and one 
or more devices. There is one exception; a device 
may attempt to reset other devices assigned to the 
same address by sending a Rctfct message co itself. 
ACCESS.bus messages have t];ie following format: 



Bytc 
Number 



Bit Number 
[12345678} 



[ destaddr 



1 sreaddr 



[p| length 



4 through 
(length + 3) 



body 



10 ] Destination 
address 

10 ] Source 
address 

) Protocol 
flag, lengtn 
(die number 
of data bytes 
from O to 127) 

) Consists 
ofOto 127 
data bytes 



length + 4 [ checksum J 

Initially, devices respond to a default powcr-up 
address. During the configuration process, the com- 
puter assigns a unique addrcs:. to every device dii 
the bus. Messages arc- cither device data Stream 
(F=0) or control/status CP=1), as indicated by the 
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protocol flag. The minimum lengch of a message is 
4 byies; the maximum length Is 131 bytes (127 data 
bytes and 4 bytes for overhead). The message 
checksum is computed as the logical XOr of all pre- 
vious bytes, including the message address. 

Staridard Messages. 

The ACCKSS.bus protocol defines the seven stan- 
dard interface messages summarized in Table 2. 
Parameters defined within the body of the message 
are listed in parentheses. 

Identification 

Since che ACCESS.bus is a bus-topology network, 
unique identification strings are used to distinguish 
devices. These strings are structure^ as follows: 



protocol revision; 
module revision: 
vendor name: 
module name; 
device number: 



I byte <e.g M -A") 

7 byres (e.g., "Xl.3 

8 bytes (e.g.. B MC ") 
8 bytes (eg., "LK501 •) 
32-bit signed Integer 

The module revision, vendor name, and module 
name strings are left-justified aSQI character 
strings padded with spaces. The device number 
string is a 32-bit two's complement signed integer 
and may be either a random number (if negative) or 
a unique serial number (if positive). 

Configuration Process 

The configuration process is used to detect whai 

devices are present on the bus, assign each device a 



unique address, and connect devices to the appropri- 
ate software driver. Configuration normally occurs 
at system stare -up, or at any time when die com- 
puter detects the addition or removal of a device. 

Poiver-up/Reset Phase 

When reset or powered up, ,3 device always reverts 
to the default address an<j sends an Attention 
message to alert the computer to its presence. At 
sysiem scarr-up or reinitialisation, the computer 
sends a Reset message to al.l PC addresses in the 
ACCESS.bus device address range (14 messages) io 
ensure that all devices on t.ac bus respond at the 
powirr-up default address. 

Identification Phase 

To begin address assignment, the computer sends 
an Identification message :it the device default 
address. Every device at rhis address must then 
respond *vith an Identification Reply message. As 
each device sends irs message, che PC arbitration 
mechanism automatically separates the messages 
based on the identification brings. The computer 
can then assign an address to each device by includ- 
ing the matching identincadian string in the Assign 
Address message, When a device receives this mes- 
sage and finds a complete mutch with the identifi- 
cation string, it moves its device address to the new 
assigned value. As soon as a device has a unique 
address, ir is allowed to send data co the computer. 

The J 2 C physical bus protocol allows multiple 
devices on the bus « the Same time if chose devices 



Table g Standard ACCESS.bus Protocol Messages 
Computer-to-device Messages Purpose 



Reset () 

identification Request () 

Assign Address (identification string, 
new address) 

Capabilities Request (offset) 



Force device to power-up mats and default 1*0 address. 

Ask device for its "identification string." 

Tell devfea with matching "identification string" to change its 
address to "new address." 

AsK device to send The fragment of its capabilities information 
that starts at "offset" 



Devjce-to-computor Messages 



Attention (status) 

Identification Reply (identification string) 
Capabilities Reply (offset, data fragment) 



Inform computer that a device has finished rts power-up/reset 
test and needs to be configured; "status" fcs the test result. 
Reply to Identification Request with device's unique 
"identification string/' ^ 

Reply to Capabilities Request with "data fragment," a fragment 
of the device's capabilities string; the computer usss "offset" 
to reassemble fragments. 
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are transmitting exactly the same message. In the 
rare event that two like devices report the same 
random number or arc mistakenly assigned to the 
same address, each interactive device transmit a 
Reset message ro its assigned address prior to send- 
ing it* first data message after being assigned a new 
address. Hie self-addressed Reset message forces 
other devices jit the same address back to the 
power-up defauJr address, as if they had just been 
hoc^IUgged. The message guarantees that each 
device has a unique address, but not until the 
device is actually used. The pseudo-random number 
(or serial number, if available) distinguishes devices 
at identification rime be/ore they are used, allowing 
the host co inventory which devices are present. 

Capabilities Phase 

Device capabakies is che scc of information chat 
, describes the functional characteristics of an 
ACCESS.bus peripheral. The purpose of capabilities 
information is to allow software to recognize and 
use the features of bus devices without prior 
knowledge of their particular implementation. By 
having locator devices report their resolution* for 
example, generic software can be written to sup- 
port a rang* c f device resolutions. Capabilities 
information provides a level of device indepen- 
dence and modularity. 

The structure of capabilities information is 
designed to be simple and compact for efficiency 
but also extensible to support new devices without 
requiring changes to existing software or periph- 
crala. These objectives are supported by making 
the structure hierarchical and representing capabil- 
ities information in a form that applications (and 
humans) can use directly. The capabilities inform* 
lion is an asch string coa^ructcd from a simple, 
t readable grammar. The grammar allows text strings 
to be formed into lists, nested lists, and lists with 
tagged dements. The capabilities string for a loca. 
lor might read as follows; 

(proTClocotar) 
typa (ntuffe) 

huttonac 1(u 2<R> 3< M ) ) 

d1 Cdnoae ( j ) j 

) 

After assigning a unique address to a device the 
computer retrieves the device's capabilic.es scrinB 
■a a series of fragments using the Capabilities 
Request and Capabilities Reply messages. The com- 



purer then parses the capabilities string to choose 
the appropriate application driver for the device. 
The parsed string is also made available to applica- 
tion programs using the device. 

Normal Operation 
. During normal operation, the computer periodi- 
cally requests inactive devices to identify them- 
selves. If a device is found to be aliasing, or a new 
device appears by sending an Attention message at 
the default address, the computer acrid* *n Identi- 
fication Requesc message Co each device address 
previously recorded as in use (up to 14 messages) to 
confirm which devices arc still present. The com- 
puter also sends a Reset message i:o each deWce 
address previously recorded as riot in use. The com- 
puter then begins the address a^icomcnt process 
by sending an Identification message to the default 
address and assigning each device tfmt responds to 
an unused device address. 

Generic Device Concepts 

ACCfiss.bus uses the concept of generic device 
drivers to support familiar I/O devices using only a 
few drivers. Generic specifications for keyboards, 
locators, and text devices have been developed. 

Keyboards 

The keyboard device protocol attempts to define 
che simplest set of functions from which a Digital 
LK201 or a common personal comparer keyboard 
user interface can be built. A generic keyboard con- 
sists of an array of key stations assigned numbers 
between 8 and 255. When any key station transi- 
tions between open and dosed, die entire list of 
key stations currently closed or depressed is trans- 
muted co the host. This reporting scheme is func- 
tionally complete; the hose can detect every key 
transition, and the scheme provides imformation 
about che full state of che keyboard on each report 
No special ^synchronization reports arc required' 
In addition to reporting key stations the generic 
keyboard device can support simp.'* feedback 
mechanisms such as keyclicks, bells, and light- 
emitting diodes. These mechanisms are controlled 
explicitly from the host so that minimal keyboard 
state modeling is required. The capabilities in/or- 
matjon is used to identify che keyboard mapping 
cable and the feedback mechanisms available T The 
keyboard mapping table can also be stored in the 
keyboard itself a* part of the capabilities siring 
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Locators 

The locator device protocol is designed to accom- 
modate a range of brcic locator device*; such as 
a mouse or tablet. More complex devices can be 
modeled as a combination of basic devices or can 
provide their own device driver; thus minimizing 
die burden on the protocol. 

A generic locator consists of one or more dimen- 
sions described by numeric values and, optionally, 
a small number of key switches, -rj lc standard driver 
requires the locator device to identify the type of 
data it «ri|| report from a small list of options and 
adjusts to handle this data type. These options are 

* Number of dimensions, e.g., two, for a mouse or 

a tablet 

■ Dimension type: absolute, I.e., referenced to 
some fixed origin, like a tablet; or relative, i.c, 
changed since last report, like a mouse 

■ Resolution in divisions per unit, e.g., counts per 
inch or counts peri-evolution 

■ Dynamic range of values that csm be reported, 
i.e., the minimum and maximum values 

• Number of key switches, from 0 to 15 

The assignment of scalar-value dimensions 
returned from one or more devices to the user 
interface functions is left to the application. How* 
ever, to accommodate most conventions, the scalar 
dimensions and the key switches can be labeled in 
the capabilities string. 

Text Devices 

The text device protocol is intended to provide a 
simple way to cransmit character dnca to And from 
Character devices such as a bar code render or a 
small character display, a generic text device trans- 
mits a stream of 8-bit bytes from a character SCL 
Simple control messages arc defined to support 
flow control and to select communication parame- 
ters thai might be used to interface with a modem. 
The capabilities string contains information ihar 
identifies the specific character set and communi- 
cation parameters used. 

Summary 

The ACCESs.bus network interconnect offers the . 
possibility of a standardized, low-speed, plug-and* 
piny eerjni communications channel that can untan- 
Sic peripheral inccrfneing and open the way to new 



applications. As the advantages of this open desk- 
top bus design become we;U known, «*e expect 
wider adoption of this product. The aCCESS.dus 
is currently implemented on Digital's Personal 
testation 5000 worksradon, with implementa- 
tions underway for the nrxt generation of RISC 
workstations and video ternno&Js. 

Ackmnvledgments 

Many people contributed tci the design and devel- 
opment of ACCESs.bus, I xirc uld especially llicc to 
acknowledge Tom Stockebr:ind and Tom Furlong 
for their vision and early support; Chris Cued, Mark 
Shcpard, and Ernie Souiiere for their contributions 
to the ACCESS.bus ekctrical tfesign Rnd protocols; 
and Aobcrt Omens for the cxceUent demonstra- 
tion hardware and firmware development support. 

General References 

D. Ueberman, "Desktop Bus; Is Bom Free," Elec- 
tronic Engineering Times (September 2. 19913: 16. 

ACC£f&bus Developer's Kit CPaJo Alto, Ca: Digital 
Equipment Corporation, Workstation Systems 
EngineerinsTW/ADD Program, 199X5. - 

Stgnetics I^C Bus Specification CSuonyvaie, q^. 
Signet jes Company, a Division of Nortfl American 
Philips Corporation, February 1987). 



Reprinted wHh permission from the DJpjtal 
Igghnfeaf JOurnaL Copyright i$ 1931 Digital 
Press/Digital Equipment Corporation, One 
Burlingion Woods Drive, Burlington, MA 01830 



*M. 3 4 frit ®S) 2K$1iaI fcfrttc*! Journal 



Received from < 703 312 6666 > at 8/19/02 2:30:29 PM [Eastern Daylight Time] 



